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Digital  Mapping,  Charting,  and  Geodesy  Analysis  Program  Technical  Review 

of  Raster  Product  Format  (RPF) 


1.0  RPF  Overview 

The  primary  goal  of  the  Raster  Product  Format  (RPF)  is  to  provide  a  common  format  to 
ease  the  interchange  of  raster  data  among  producers  and  users.  Typical  raster  images  to 
be  implemented  in  the  RPF  are  scanned  maps  and  images  (basically,  rectangular  arrays 
of  pixel  values).  Any  related  application  software  should  be  able  to  access  data  in  the 
RPF  without  further  manipulations  or  transformations. 

The  major  components  distinguishing  RPF  from  its  predecessor.  Raster/ Gridded 
Product  Format  (RGPF),  are  the  omission  of  gridded  products  from  the  format  and  the 
implementation  of  National  Imagery  Transmission  Format,  Version  2.0  (NITF).  The 
draft  RPF  on  which  this  review  is  based  is  defined  by  three  documents:  Raster  Product 
Format  [4],  Registered  Data  Values  for  Raster  Product  Format  [5],  and  Integration  of  Raster 
Product  Format  Files  into  the  National  Imagery  Transmission  Format  [3].  Additionally,  an 
RPF  prototype  product.  Compressed  Equal  Arc-Second  Digitized  Raster  Graphics 
(CADRG),  described  in  [2],  is  included  as  part  of  this  review. 

1.1  As  a  Stand-Alone  Format 

As  a  stand-alone  format,  the  RPF  would  suffice  as  a  structure  for  raster  products.  It  is  a 
comprehensive  and  well-designed  format  for  geospatial  image  data.  The  adoption  of 
NITF,  as  well  as  the  omission  of  gridded  products,  was  a  clear  enhancement  over  the 
RGPF.  Only  minor  considerations  would  need  to  be  addressed  if  the  RPF  were  to  be 
formally  adopted  (most  of  these  comments  are  summarized  in  Appendix  A). 

1.2  As  Part  of  a  GGIS  (Global  Geospatial  Information  and  Services)  Concept 

The  fundamental  approach  of  RPF  offers  minimal  capability  for  supporting  advanced 
data  processing  of  raster  data  with  other  types  of  data,  namely,  vector  data  in  the 
Vector  Product  Format  (VPF)  and  text  in  the  proposed  Text  Product  Standard  (TPS),  or 
more  specifically,  with  their  associated  metadata.  Significant  effort  would  be  required 
by  users  to  reformat  RPF  data  to  support  its  integrated  processing  with  relational-based 
VPF  databases. 

RPF  developed  around  the  ARC  tiling  scheme  developed  for  ADRG.  While  this  type  of 
approach  to  developing  a  standard  is  conventional,  it  will  not  adequately  support  the 
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move  towards  a  Defense  Mapping  Agency  (DMA)  Global  Geospatial  Information  and 
Services  (GGIS)  concept.  For  the  GGIS  initiative,  the  World  Geographic  Reference 
System  (GEOREF)  tiling  scheme  of  VPF  products  will  be  utilized. 

In  a  traditional  Geographic  Information  System  (GIS),  the  user  is  blind  to  the  many 
rudimentary  operations  that  must  be  undertaken  to  provide  an  appearance  of  merging 
gridded,  raster,  vector,  and  text  data  together  to  support  common  queries,  overlays, 
and  displays.  Recently,  the  use  of  integrated  data  structures,  which  provide  topological 
linkage  between  these  data  types,  has  become  effective  in  supporting  more  advanced 
spatial  data  processing  environments.  The  merger  of  relational  data  structures  with 
object-oriented  programming  extensions  provides  the  optimistic  user  with  a  myriad  of 
choices  for  supporting  fully  integrated  topologically  based  processing.  Within  such  an 
environment,  raster  and  vector  datasets  can  more  easily  be  georeferenced  to  relational 
tables  of  both  meta  and  attribute  data.  To  accomplish  this  type  of  seamless  integration, 
DMA  must  utilize  more  advanced  data  structures  that  address  combining  data  storage 
mechanisms  for  raster,  gridded,  vector,  and  text  data.  This  utilization  would  require  a 
move  away  from  the  current  approach  of  developing  a  separate  RPF  to  one  which 
merges  the  raster  data  format  with  other  standards  like  the  current  VPF  and  the 
proposed  TPS. 

In  brief,  RPF  could  not  easily  be  used  with  multiple  vector  layers  in  a  relational 
database  management  environment,  a  future  relational/ object-oriented  combination,  or 
a  purely  object-oriented  environment,  which  are  the  directions  that  digital  Mapping, 
Charting,  and  Geodesy  will  most  likely  move.  The  primary  reasons  are  as  follows: 

i.  RPF  metadata  are  stored  differently  than  currently  accepted  VPF 
metadata. 

ii.  Current  RPF  products  use  a  different  framing/  tiling  scheme  than  current 
VPF  layers  that  will  likely  comprise  the  GGIS. 


2.0  Related  Formats/ Standards 

The  RPF  is  closely  associated,  by  the  nature  of  its  purpose,  with  two  accepted 
formats/ standards:  Spatial  Data  Transfer  Standard  (SDTS)  [8],  a  standard  allowing  ease 
of  transfer  of  various  spatial  data,  and  the  NITF  [1],  a  standard  for  imagery 
transmission. 
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2.1  SDTS 


Usage  of  SDTS  becomes  mandatory  for  Federal  agencies  on  15  February  1994.  In  its 
introduction,  [8]  states 

SDTS  provides  a  solution  to  the  problem  of  spatial  (i.e.,  geographic  and 
cartographic)  data  transfer  from  the  conceptual  level  to  the  details  of  physical 
file  encoding.  Transfer  of  spatial  data  involves  modeling  spatial  data  concepts, 
data  structures,  and  logical  and  physical  file  structures.  To  be  useful,  the  data 
to  be  transferred  must  also  be  meaningful  in  terms  of  data  content  and  data 
quality.  SDTS  addresses  all  of  these  aspects  for  both  vector  and  raster  data 
structures. 

DMAP  recommends  that  SDTS  be  further  examined  to  determine  its  relationship  to  the 
RPF.  Whereas  SDTS  is  strictly  concerned  with  data  transfer  (e.g.,  no  tiling  structure  is 
employed  by  SDTS  since  it  increases  data  structure  complexity),  its  mandated  use  and 
application  to  raster  image  data  should  merit  a  reference  as  to  how  it  could  relate  to  the 
RPF.  Also,  the  journal  Cartography  and  Geographic  Information  Systems,  Vol.  19,  No.  5, 
1992  is  a  special  issue  that  focuses  on  SDTS  and  its  requirements.  In  particular,  the 
article  [7]  is  especially  recommended  for  review. 

2.2  NITF 

Conforming  to  NITF  makes  RPF  products  accessible  to  users  on  different  platforms  and 
more  in  line  with  DOD/IC  interchange  requirements  but  further  from  GGIS  goals  and 
interproduct  compatibility  (see  disadvantage  ii). 

Some  of  the  advantages  of  having  NITF  include  the  following: 

i.  NITF  is  one  in  the  group  of  standards  adopted  for  the  GGIS 
initiative.  NITF  was  designed  to  provide  a  common  digital  storage 
and  interchange  format  across  diverse  platforms  making  it  consistent 
with  the  intent  of  GGIS. 

ii.  NITF  provides  numerous  user  formatted  data  areas.  One  of  the 
initial  problems  with  the  RGPF  was  that  of  storage  of  ancillary  data 
(e.g.,  satellite  imagery  headers,  alternate  display  parameters,  etc.). 

NITF  has  several  areas  where  tagged  user  fields  of  any  format  may 
be  located. 
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iii.  NITF  provides  a  flexible  format  that  allows  multiple  images  in  a 
single  logical  structure.  The  RPF  format  alone,  which  allows  only  a 
single  image  per  file,  could  become  clumsy  if  a  future  product 
required  multiple  images. 

iv.  NITF  provides  a  known  structure  for  which,  presumably,  software 
would  be  widely  available  to  DMA  users.  Because  several  of  the  RPF 
image  description  tables  have  been  placed  alongside  the  image,  some 
generic  NITF  software  may  be  able  to  display  the  RPF  image.  This 
could  be  an  advantage  to  the  incidental  user  of  the  RPF  format 
products. 

Some  of  the  disadvantages  of  having  NITF  include  the  following: 

i.  NITF,  as  with  most  additional  software  layers,  carries  an  overhead 
penalty.  There  are  many  duplicate  fields  between  the  NITF  and  RPF 
formats,  making  storage  requirements  greater  and  the  chances  for 
data  inconsistencies  more  likely. 

ii.  NITF  worsens  the  metadata  access  problems  between  RPF  and  VPF. 
NITF  adds  another  data  format  that  software  has  to  manage  in  order 
to  gain  information  on  the  contents  of  an  RPF  product. 

iii.  Inserting  the  RPF  fields  into  NITF  could  probably  be  better  done  by 
redesigning  the  RPF  using  existing  NITF  fields  where  possible,  as 
was  done  with  Digital  Point-Positioning  Databases.  This  would 
avoid  the  duplication  of  fields  while  maintaining  NITF's  flexibility 
and  character-based  format. 


3.0  Tiling 

The  fundamental  approach  to  tiling  in  the  RPF  is  to  build  upon  parts  of  the  ARC 
tiling/ zoning  scheme  developed  for  ADRG.  The  specification  clearly  uses  the  same 
zones,  but  it  is  unclear  if  RPF  will  continue  using  the  global  tiling  scheme  used  in 
ADRG  (padding  with  black  pixels  to  form  images  whose  dimensions  are  multiples  of 
128  pixels,  specifying  projections  for  the  polar  and  nonpolar  zones,  specifying 
projection  origins,  etc.).  Since  [5]  contains  registered  values  for  many  projections, 
whereas  ADRG  allows  for  only  two,  the  specification  is  confusing.  Nevertheless,  the 
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usage  of  the  ARC  zones  hinders  interoperability  with  VPF,  in  which  most  products 
employ  the  GEOREF  tiling  scheme. 

Further  adding  to  the  confusion  regarding  tiling  is  the  example  given  on  p.  20,  Section 
5.1.2  in  [4].  A  typical  map  [frame  file]  shall  be  256  x  256  pixels,  which  is  clearly  a 
multiple  of  128  (i.e.,  agrees  with  ADRG).  A  typical  frame,  in  turn,  will  be  composed  of  a 
6x6  matrix  of  subframes.  These  dimensions  imply  that  a  subframe  does  not  have  an 
integral  number  of  pixels  for  its  dimension  (6  does  not  divide  256),  unless  of  course 
variable  subframe  sizes  are  allowed. 

The  RPF  should  clearly  define  its  tiling  scheme  and  any  deviations  from  ARC  this 
scheme  may  have.  If  RPF  is  accepting  the  ARC/ ADRG  approach  as  standard,  then 
reasons  for  its  selection  over  GEOREF  should  be  provided.  (Note:  GEOREF,  for  all 
practical  purposes,  appears  superior  to  ARC/  ADRG:  it  allows  for  a  variety  of  tile  sizes, 
its  addressing  scheme  is  sufficiently  compact  to  permit  a  combination  of  four  letters  and 
four  numbers  to  reference  any  point  on  the  earth  to  within  1  nautical  mile,  which  allows 
for  an  efficient  file-naming  scheme.  RPF  file  naming  relies  on  codes  from  producers.) 


4.0  Imagery  (Non-Chart  Data) 

One  of  the  initial  concerns  with  the  RPF  was  its  capability  of  handling  a  variety  of 
remotely  sensed  multispectral  imagery  (MSI),  taken  from  such  sensors  as  LANDSAT 
TM,  SPOT,  and  AVIRIS.  Although  prototypes  of  CADRG  imagery  were  available  in  the 
RPF,  no  MSI  prototypes  were  evaluated  for  this  review.  However,  the  RPF  appears  to 
provide  an  acceptable  format  for  MSI.  The  NITF,  with  its  tagged  data  extensions, 
allows  storage  of  information  not  expressly  defined  in  the  format  (e.g.,  sun  angle  at  time 
of  collection  of  TM  image). 

Although  RPF  fields  exist  to  adequately  describe  such  attributes  as  dimensions  of  the 
data,  areal  coverage,  and  spatial  resolution,  a  remaining  concern  is  the  fact  that  some 
users  may  want  raw  unprocessed  data,  where  little  or  no  corrections  have  been  applied. 
For  example,  LANDSAT  TM  is  available  in  a  variety  of  map-oriented  formats  (system 
corrected,  precision  corrected,  terrain  corrected),  georeferenced  to  the  user's 
specification  of  scale,  datum,  projection,  etc.  However,  the  possibility  of  obtaining  raw 
TM  data  still  exists. 

While  the  RPF  allows  for  the  capability  of  storage  of  nongeorectified  data,  its  strong 
connection  with  the  ARC  zoning  scheme  (for  filename  extensions,  etc.)  may  lead  to 
confusion.  An  alternative  approach  would  be  to  eliminate  any  dependence  on  the  ARC 
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scheme,  or  state  fully  the  relationship  of  RPF  with  ARC  and  why  this  relationship  is  not 
prohibitive,  if  indeed  that  is  the  case. 


5.0  CADRG  Prototype  3.0  Comments 

In  comparing  the  CADRG  specification  to  the  RPF  several  discrepancies  were  found. 
These  are  listed  in  Appendix  B. 


6.0  Key  Issues 

Summarized  below  are  the  key  points  made  in  this  review: 

1.  The  concept  of  RPF  tiling  should  be  clarified,  specifically  as  it  relates 
to  VPF  products  that  will  likely  populate  the  GGIS. 

2.  "Nonchart"  imagery  such  as  remotely  sensed  data  (e.g.,  LANDSAT 
TM  map-oriented)  needs  to  be  given  more  detailed  treatment  in  the 
specification. 

3.  Unprocessed  imagery  (not  georeferenced  to  a  particular  datum  or 
chart)  should  be  given  more  attention,  as  some  users  of  raster  data 
prefer  imagery  uncorrupted  by  transformations,  stretching,  etc.  The 
choice  of  ARC  zones  and  chart  series  used  in  file  naming  may  cause 
confusion. 

4.  SDTS  should  be  reviewed  as  a  part  of  the  RPF. 

5.  Although  not  discussed  in  this  review,  the  issue  of  gridded  data 
remains  unresolved. 

6.  The  comments  and  corrections  listed  in  Appendix  A  should  be 
addressed  in  the  RPF  documents  before  the  raster  standard  is 
upgraded. 

7.  The  CADRG  specification  and  the  RPF  disagree  as  noted  in 
Appendix  B. 
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7.0  Recommendations 


This  version  of  a  raster  product  standard  should  not  be  accepted  in  its  present  form. 
The  primary  reason  is  its  inability  to  adequately  complement  advanced  relational  (or 
object-oriented)  database  environments. 

The  design  of  the  RPF  format  should  be  reconsidered  from  the  standpoint  of 
interoperability  with  VPF  products  and  with  database  management  systems  (DBMS)  in 
general.  DMA  has  recently  expended  significant  resources  developing  VPF  as  a 
georelational  database  structure.  VPF  data  products  will  be  readily  imported  into  GISs. 
The  metadata  and  attribute  data  contained  in  VPF  are  readily  imported  into  relational 
database  management  systems  (RDBMS).  Once  imported,  the  data  may  be  fused  with 
other  data  and  exploited  using  the  power  of  the  RDBMS  and  GIS. 

A  new  raster  product  standard  should  be  constructed  around  the  following  concepts: 

1 .  Store  all  metadata  in  a  VPF-type  format  that  RDBMS  can  exploit.  The  use  of 
such  relational  tables  for  RPF  metadata  would  allow  raster  and  vector  data  to 
be  queried  in  a  consistent  manner. 

2.  Introduce  new  standardization  of  storage  for  raster  data  sets  only  at  the  actual 
level  where  current  VPF  standardization  becomes  unsuitable.  For  example,  the 
VPF  table  format  may  be  useful  in  a  raster  standard.  The  VPF  concepts  of  ’ 
library  and  coverage  may  also  apply.  A  common  tiling  scheme  may  be  agreed 
upon  for  both  the  VPF  and  RPF. 

Finally,  an  integrated  spatial  data  standard  should  be  pursued  long  term  to  combine 
raster,  gridded,  text,  and  vector  data  together  for  optimum  GIS  and  RDBMS 
exploitation.  This  approach  is  different  from  the  original  DMA  plan  to  develop  three 
overall  standards  for  data  (raster,  vector,  text)  and  is  especially  recommended  now  with 
the  advent  of  GGIS. 
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Example  diagram  showing  bourn 


Appendix  A.  Comments  on  References  [4],  [5],  and  [3]. 

[4]  MIL-STD-2411 

p.  7  There  are  references  throughout  the  document  to  gridded  products,  which  are  no 
longer  part  of  the  RPF.  One  example  is  on  p.  7,  Section  4.a.  More  are  located  on  p.  20, 
Section  5.1.1  (elevation  post  values),  and  p.  28,  Section  5.1.9. 

p.  7  Arc  should  be  ARC  ("Equal  Arc-Second  Raster/ Chart  Map"). 

p.  12  In  Section  4.4.2.1,  move  "Note:  A  denotes  exponentiation."  above  the  first 
occurrence  of  the  "A"  symbol.  Also,  be  consistent  with  subtraction  spacing:  second 
equation,  S4.4.2.1,  "B  - 1." 

p.  19  A  decision  should  be  made  between  <chart  series  and  zone>  or  <data  series  and 
zone>.  MIL-STD-2411-1  uses  the  latter. 

p.  21  How  does  one  distinguish  between  different  boundary  rectangles?  This  question 
is  answered  in  the  diagram  on  p.  31  (reference  each  boundary  rectangle  by  the  lat/long 
vertices),  but  this  also  needs  to  be  mentioned  in  the  text.  Section  5.1.3  on  p.  21  since 
should  probably  mention  this  detail,  since  that  is  where  frame  and  subframe  referencing 
is  described. 

p.  21  Different  variables  should  be  used  to  describe  subframe  size  in  sections  5.1.3.C.1 
and  5.1.3.C.2  since  N  and  M  were  used  to  describe  frame  size  in  5.1.3.b.l  and  5.1.3.b.2.  A 
figure  (an  example  is  given  in  Fig.  1)  showing  the  way  in  which  frames  and  subframes 
are  referenced  within  boundary  rectangles  is  recommended. 

p.  21  Section  5.1.3.d:  /image  codes/s  should  b e  /image  code/s 

p.  22  Section  5.1.4:  RPF-comatible  should  be  RPF-compatible 

p.  22  Section  5.1.4:  use  should  be  uses 

p.  27  Section  5.1.8:  .c.5.1.8  should  be  5.1.8 

p.  27  Section  5.1.8:  intented  should  be  intended 

p.  27  In  addition  to  the  various  <...  record  length>  fields  intended  for  backward 
compatibility,  <header  section  length>  should  also  be  mentioned  as  intended  for 
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backward  compatibility.  Moreover,  in  the  logical  element  alphabetical  listings  later  in 
the  text,  <section/ component  location  record  length>  is  not  mentioned  as  being 
intended  for  backward  compatibility.  This  needs  to  be  corrected  in  the  listings  or  the 
exception  of  this  particular  record  length  noted  on  p.  27. 

p.  28  MIL-STD-2411-1  is  still  referred  to  as  "the  handbook"  in  Section  5.1.10.  The  title 
of  that  document  has  changed. 

p.  30  Part  of  a  sentence  is  left  off  in  Section  5.2.1. b. 2.  See...? 

p.  31  How  does  one  determine  a  boundary  rectangle?  Is  there  a  standard  or  logical 
method? 

p.  35  Beginning  on  this  page  and  throughout  the  remainder  of  this  standard,  references 
to  MIL-STD-2411-1,  Section  4  should  be  references  to  Section  5.  In  Section  5.2.1. d  of  the 
RPF  standard,  this  reference  error  is  found  in  the  following  elements:  5, 11, 12, 13, 43, 
44, 45, 46,  51, 52, 53,  and  58.  In  Section  5.2.2.C  of  the  RPF  standard,  this  reference  error  is 
found  in  the  following  elements:  3,  9, 13, 14, 20, 24,  79,  86, 89,  94, 95,  and  96.  In  Section 
5.2.3.d  of  the  RPF  standard,  this  reference  error  is  found  in  the  following  elements:  4, 

21,  22,  and  23. 

p.  35  Section  5.2.1.d.4:  [color  index  record  should  be  [color  index  record] 
p.  35  Section  5.2.1. d.6:  pixels  should  be  pixel 
p.  39  In  (48),  lenght  should  be  length. 
p.  41  In  (6),  section  "TBD"  should  be  resolved. 

p.  46  In  Fig  3,  [relateed  images  subsection]  should  be  [related  images  subsection] 

p.  48  Beginning  on  this  page,  the  numbering  of  [frame  file]  elements  is  incorrect.  The 
following  numbers  are  missing:  (11),  (12),  (17),  (23),  (35),  (78),  and  (85). 

p.  56  Section  5.2.2.c:  (49)  and  (50)  should  be  (92)  and  (93) 

p.  50  Section  5.2.2.C.33:  <hostogram  should  be  <histogram 

p.  51  Section  5.2.2c(37)  is  missing  ">"  symbol:  "<image  code  bit  length" 
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p.  54  Section  5.2.2.C.75:  previously  should  be  previous 
p.  54  Section  5.2.2.C.75:  field>  should  be  field 

p.  55  Section  5.2.2c(83):  the  first  sentence  needs  to  be  simplified  into  possibly  two  or 
more  sentences. 

p.  56  Section  5.2.2.C.87:  [replace/,  up  date  should  be  [replace/update 
p.  57  Section  5.2.2c(101)b  is  missing  a  ")"  symbol, 
p.  58  Section  5.2.2c(103)b  is  missing  a  ")"  symbol, 
p.  62  Section  5.2.2c(62)  is  missing  the  ending  period, 
p.  62  Section  5.2.3.d.l2:  <hostogram  should  be  <histogram 

[5]  MIL-STD-241 1  -1 

p.  7  Section  5.1.2:  define  should  be  defines 

p.  7  Section  5.1.2.a:  in  following  should  be  in  the  folloxoing 

p.  11  Section  5.1.6:  CDTED  and  DTED  are  gridded  products  and  are  not  supported  in 
RPF 

p.  17  Specify  that  VQ  stands  for  Vector  Quantization  in  the  given  tables. 

p.  26  Section  5.3.2.2:  Why  are  datum  codes  allowed  in  the  RPF?  Horizontal  datum  is 
specified  in  MIL-STD-2411  as  WGS  84. 

p.  42  Section  5.4  used  should  be  use 

In  general,  this  standard  is  well-organized  and  adequately  fulfills  its  purpose  as  a 
companion  standard  to  MIL-STD-2411. 
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[3]  MIL-STD-2411-2 


p.  6  In  MIL-STD-2411,  [rpf  mask  subsection]  is  actually  divided  up  into  two  tables,  [rpf 
subframe  mask  table]  and  [rpf  transparency  mask  table].  To  maintain  consistency 
between  the  standards,  it  is  recommended  that  the  same  headings  be  used  in  both 
documents. 

p.  6  The  ordering  of  the  [rpf  frame  file]  sections,  although  correct,  differs  from  the 
ordering  presented  in  MIL-STD-2411  on  p.  40.  The  two  orderings  should  be  the  same 
for  consistency,  as  are  the  [rpf  table  of  contents  file]  and  [rpf  external  color/ grayscale 
file.] 

p.  7  What  is  meant  by  NITF  message  should  be  made  more  clearly  in  the  standard. 

p.  8  In  Section  5.3,  [rpf  component]  is  mentioned  in  each  of  the  tables.  The  standard 
needs  to  specifically  state  what  is  meant  by  this  heading  and  which  sections  are 
included  within  it. 
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Appendix  B.  Comments  on  Reference  [2]  compliance  with  RPF. 

1.  Four  fields  under  the  heading  [Mask  subsection]  should  appear  at  the  beginning  of 
the  [Image  display  parameters  subheader] .  These  fields  include 

<all  blocks  present  indicator> 

<no  transparent  pixels  present  indicator> 

<block  sequence  record  length> 
ctransparency  sequence  record  length> 

2.  The  [Block  mask  table]  and  [Transparency  mask  table]  should  appear  after  all  of  the 
required  header  information  in  the  [Image  display  parameters  subheader]. 

3.  The  [Mask  subsection]  designation  has  been  removed  from  the  RPF  format  and 
should  be  removed  from  the  CADRG  specification. 

4.  File  name  case  (upper/ lower)  should  be  consistent  with  the  requirements  of  the 
platform.  In  UNIX,  lower  case  is  needed. 
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Appendix  C.  Acronyms. 


ADRG  ARC  Digitized  Raster  Graphics 

CADRG  Compressed  ARC  Digitized  Raster  Graphics 
DBMS  Database  Management  System 

DMA  Defense  Mapping  Agency 

DMAP  Digital  Mapping,  Charting,  and  Geodesy  Analysis  Program 

DTED  Digital  Terrain  Elevation  Data 

GEOREF  World  Geographic  Reference  System 

t  GGIS  Global  Geospatial  Information  and  Services 

GIS  Geographic  Information  System 

MSI  Multispectral  Imagery 

NITF  National  Imagery  Transmission  Format 

RDBMS  Relational  Database  Management  System 

RGPF  Raster / Gridded  Product  Format 

RPF  Raster  Product  Format 

SMap  Scanned  Map 

TPS  Text  Product  Standard 

VPF  Vector  Product  Format 

WGS84  World  Geodetic  System  1984 
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